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Description 

The invention relates to a method and a system for mutual exdush/e control of resources sequentially avail- 
able In an event driven process. The sequentially available resources to be controlled are resources that are 
5 controlled by a computer, a programmable logic controller or the like. 

Important subjects In the recent computer technology are multitasking, multiprocessing and distributed 
processing. To implement these techniques, it Is necessary to share a resource between several tasks or proc- 
esses during parallel execution of a plurality of tasks or processes. Such a resource is called a shared resource, 
vt^hich includes, for example, various peripheral devices, disks, memories, communication lines, programs, and 
10 data. A shared resource that is allowed to be appropriated to one task or process at a time is called a critical 
resource. 

The problem of mutual exclusive control of resource in an event driven process arises when event driven 
processes are executed in parallel, and they use the shared resource. The mutual exclusive resource control 
is a mechanism for assuring that the shared resource will be held by at most one process. An area which holds 

IS a shared resource in the processes executed in parallel is called a critical section. It is a problem of sharing a 
resource when a plurality of tasks are executed in parallel, and is presented as a problem of interprocess com- 
munication and synchronisation. To solve it. conventionally, various techniques are proposed, and it is analysed 
by a model for use in a system. The synchronisation problem includes the mutual exclusion problem, the pro- 
ducer consumer problem, the dining philosopher problem, or the readersAwriters problem. 

20 At present, there is no way of solving a problem of the mutual exclusive resource control between a plurality 

of processes, which is important in implementing a parallel execution system, but a programmer carefully 
writes, by using semaphores. Thus, when a programmer writes a program executing in parallel, or when an 
operator executes a program under such environment, attentbn rmjst be always payed to resource assignment 
It is a burden for the programmer or the operator. 

25 An example of programming using semaphores will be explained below. Now, it is assumed that there are 

three flows of event driven processes Gi, G2 and G3 schematically shown in Figure 2. In the first flow of process 
Gi, tasks Pi and P2 are sequentially processed. After the task Pi is executed while using shared resources A 
and C, the task p2 is executed while using shared resources B and C. 

In the second flow of process G2, a task P3 is executed. The task P3 is executed while using the shared 

30 resources A, B and C. In the third flow of process G3 tasks P4 and P5 are executed in parallel. The task P4 is 
executed while using the shared resources A and C, and the task P5 is simultaneously executed while using 
the shared resources B and C. ti - tj indicate start or end points of the tasks. It is assumed that, among the 
resources appearing in Figure 2, critical resources are A and B, and that the critical resource A Is a robot 2, 
while the critical resource B is a robot 1 . 

35 At present, in most cases, programming is performed on each critical resource (controller for production 

apparatus in a manufacturing process, or a computer in a network system), which requires a program on each 
critical resource and a program for controlling them. An example of this is shown in Figure 3. Figure 3A is a 
program for controlling the entire system. Figure 3B being a program for the robot 1 . Figure 3C being a program 
for the robot 2. 

40 Here, syntax for describing the parallel execution is as follows: 

cobegin 

P1; 
P2 

coend 

45 wherein P1 and P2 are tasks executed In parallel. 

In addition, syntax for describing a critical section is as follows: 
with R do 

begin 

S 

50 end 

wherein R is a unique name for a critical resource to be mutually excluded, and S is a critical section to be 
mutually excluded. In this case, R is a semaphore. 

In Figure 3A, R(p) is a program for a robot indicated in Figures 3B and 3C, respectively. When a parameter 
p is passed to R, the program for R executes only the task for p. 

55 The syntax for describing the critical section and its mechanism, as well as the syntax for describing the 

parallel execution and its mechanism are not supplied to the programmer generally, so that it becomes respon- 
sibility of the programmer to write the description, to produce its mechanism, and to debug the mutual exclusive 
control. 
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Now. there is one technique called Petri-Net that is widely used for modelling of a system. Features of the 
Petri-Net are parallelism orsimultaneousness and asynchrontsm. Its execution may be considered to be a ser- 
ies of discrete events, and the timing when an event occurs is indefinite. It has been attempted to utilise these 
features and the execution form for the event driven control. The Petri-Net is also used in simulation of a parallel 
5 execution system (a computer nrwdel. or a manufacturing process) by noticing its good mathematical analysis 
characteristics and high nrK>delling capability. 

Now, the overview of Petri-Net will be explained. 

The Petri-Net consists of four components: a place, a transition, an arc, and a token. The place Indicates 
an event, the transition indicates a condition, the arc indicates a path, and the tolcen Indicates a state. The 

10 token moves In the arc between the places according to the conditfon of the transition, and causes an event 
corresponding to the place. 

Figure 4 shows an example of executk)n of the Petri-Net In this example, explanation is made by using 
a transition T = {t^. tt. tj. place P = {P,. Py, PJ. and a token. First, if there is no token in P^, ta generates a 
token and places it in P, (Figure 4A). If P^ has a token, and Py and P^ do not have a token, transfers the 

15 token to Py and P^ (Figure 4B). Py and P^ have a token, tc takes out and erases the token. For the details of 
the Petri-Net. reference should be made to Peterson, J. L, "Petri Net Theory and the Modelling of Systems." 
Prentice-Hall Inc.. 1981. 

Recently, a system is proposed wherein a programmer describes a flow of processes as shown in Figures 
2 or Figure 4 by using a graphic editor, and converts it into codes to create a program for controlling the entire 
20 system so that, while instructing start of the task or receiving a termination signal, the token ts automatically 
transferred according to these signals based on the program in execution. For example, reference should be 
made to Hasegawa. K. and Takahashi, K.. "MFG (Mark Row Graph)-Based Programmable Controller and its 
Application to FMS," Proceedings of the International Conference on System Engineering, pp. 306 - 311 , f 984. 

Also, reference should be made the document by K. Hasegawa et al.: 'MFG (Mark flow graph)- based pro- 
25 grammable controller and its application to FMS'. which shows the use of a Mark Flow Graph (MFG) deduced 
from the Petri net A nnarked flow graph is stored in a programmable controller and is used in a control system 
having among its properties; asynchronism and concurrency. In the nodes of the graph, called txixes and in- 
dicating the condition of a system dement are stored marks or tokens to control the system state. A transition 
is uniting are or more input boxes with one or more output boxes. The firing of a transition to another system 
30 state is performed only when all input boxes have marks therein. 

However, none of these conventional control systems takes the mutual exclusive control into considera- 
tion. 

Although it is for an aspect in modelling rather than programming, modelling of the mutual exclusive control 
is performed by creating a place corresponding to an empty state of resource (empty place), connecting it to 

35 a place of a task using that resource to establish a critical section. In this case, it utilises storability that is an 
important characteristic of the Petri-Net The empty place contains a token as an initial marking, and always 
contains a token when a resource is not used. When a process Is in a critical section, and using a resource, 
the empty place does not contain a token. If another process attempts to enter the critical section for using 
the same resource, it cannot be executed because the empty place does not contain a token and a fire condition 

40 is not satisfied. Execution of another process is caused to wait until the process using the resource ends, re- 
leases the resource, and returns the token to the empty place. 

Figure 5 shows an example of such modelling. Place m indicates authorisation to enter a critical section. 
When a process wants to enter the critbal section. It supplies a token to Pi or P2 issuing a sign that indicates 
its wish to enter the critical section, and waits for a sign allowing entrance into the critical section or the token 

45 of m to access the critical section. If both processes want to enter the critical section, transitions ti and tj cause 
contention, and only one of them can be fired. Fire of t, disables that of tj, and the process 2 is caused to wait 
until the process 1 completes the critical section and returns the token to m. 

Then, can the mutual exclusive control be easily implemented if a graph having empty places for critical 
resources is created, and converted into codes so as to create a control program for the entire system taking 

50 the mutual exclusive control into consideration, and the token is automatically transferred as the system de- 
scribed in the abK>ve reference (2)? Unfortunately, the answer is "No." The reason is described below. 

(1) First, empty places must be incorporated in the Petri-Net If a programmer incorporates the empty plac^ 
es In a suitable location in the Petri-Net while paying attention to critical resources, his effort will be equiv- 
alent to programming using semaphores. The creation of the Petri-Net becomes very difficult for a slightly 

55 complicated case as Figure 6 compared with a simple case as Figure 5 aside. 

(2) In execution, a user must first distinguish the empty places (resource places) from task places, and 
then place initial tokens in all empty places. This imposes a significant burden on the user 

(3) A deadlock may be caused from the representation of the Petri-Net itself. 
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Now, it is explained by taking Figure 6 as an example. It is assumed that the current state is as shown in 
Figure 6A. That is. the tasks Pi and P4 are being executed, and the resources Px and Py are empty. The resource 
Px is used by the tasks P2, P3 and Pe- The resource Py is used by the tasks P3. Ps and Pe- 

If the state is as shown in Figure 6A. then it is dear that the control system can start the execution of the 

5 tasks P2 and P5. Thus, t^ and transfers the tokens to P2 and P5, respectively. Here, it should be noted that 
because the representation as shown in Figure 5 or Figure 6 connects each end of the critical section to the 
empty place of the resource, the token is never transferred to the empty place of Px until the execution of the 
task P3 following the task P2 is completed . and that, similarly, the token is never transferred to the empty place 
of Py until the execution of the task Pe following the task P5 is completed. Figure 6B shows the positions of the 

10 tokens after starting the execution of the tasks P2 and P5. Now. the control system cannot start the execution 
of the task P3 even if the execution of the task P2 is completed because there is no token in the empty place 
of Py. A token is never returned to the empty place of Px unless the executton of the task P3 is started. Thus, 
the execution of the task Pe is also not started. In this way. the transitions t2 and ts cannot fire and thus causes 
a deadlock. In the Petri-Net. transitions that cannot fire or their set is called a deadlock. 

15 In a mathematical representation, G = (P. T, O) where G is the Petri-Net structure. P = {P,, P2. ... Pm) "S a 

set of places and M > O. and T = (T,. T2. ... TJ is a set of transitions and L > 1 . The set of places and the set 
of transitions are disjoint, and P 0 T = 4». I : P T is an input function from a place to a transition. O : T P 
is an output function from a transition to a place. A Petri-Net structure to which a marking \i for assignment 
of a token to a place Is added is called a marked Petri-Net. The token exists only in the place, and fire of the 

20 transition controls execution. Fire of the transition transfers a token from an input place to an output place. 
The Petri-Net structure is dual in the graph theory. The concept of dual of a graph is not utilised in the niarked 
Petri-Net because the dual of a graph is difficult to define. 

A method for mutual exclusive resource control according to the present invention comprises steps oft 

(a) generating a graph and retaining the graph in a storage apparatus, the graph comprising nodes to which 
25 tasks included in a process flow and a critical resource, which may be appropriated by at least one of the 

tasks, are mapped, nodes of tasks executed sequentially being arranged in series, nodes of tasks executed 
in parallel being arranged in parallel with each other, a node of critical resource being arranged in parallel 
with every node of the task that may appropriate the critical resource; and 

(b) each time a signal for beginning execution of a task is transmitted, generating a token in the node of 
30 the task and the critical resource node in parallel therewith; and 

(c) when the end of execution of the preceding task in the process flow is detected, referring to said graph; 
and causing the transmission of a signal for beginning execution of the immediately succeeding tasks to 
wait while a token is assigned to at least one of the immediately succeeding task node and the critical re- 
source node arranged in parallel therewith. 

35 It is preferable, in the step (a), to provide nodes of the gates in the graph at a location where nodes of the 

tasks being sequentially executed are connected; 

in the step (b), every time the completion of the execution of a task is detected, to remove the node of 
the task and a token assigning to a critical resource that is arranged in parallel to that node; and 

when completion of execution is detected for tasks corresponding to every task node arranged imme- 
40 d lately before a gate node, to generate a token in the gate node, and then, while a token is assigned to any 
one of a node for a succeeding task arranged immediately after the gate node or a node of a critical resource 
arranged in parallel with it. to cause the transmissbn of a signal for beginning the execution of the succeeding 
task to wait by referring to the graph; and to 

remove the token from the gate node after the transmission of the signal for beginning the execution 
45 of the succeeding task. 

A preferred system for mutual exclusive resource control according to the invention comprises a storage 
device holding a graph that has tasks contained in a flow of process and nodes corresponding to a critical re- 
source capable of being exclusively appropriated by any of the tasks, and in which nodes of tasks being se- 
quentially executed are arranged In serial, nodes of the tasks being executed in parallel being arranged in par- 
50 allel with each other, a node of a gate being arranged at a location connecting the nodes of the tasks with each 
other, a node of a critical resource being arranged in parallel with the nodes of ail tasks capable of exclusively 
occupying the critical resource; 

a means for generating tokens in a node of the task in the graph and in a node of a critical resource 
arranged in parallel with the node every time a task beginning signal is transmitted; 
55 a means for removing the tokens assigning to the node of the task and to the node of the critical resource 

arranged parallel with the node every time the end of the executfon of the task is detected; 

when a completion of execution is detected for tasks corresponding to every task node arranged irT>- 
mediately before a gate node, generating a token in the gate node, and then, while a token exists in any one 
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of a node for a succeeding task arranged immediately after the gate node or a node of a critical resource ar- 
ranged in parallel with it. causing the transmission of a signal for beginning the execution of the succeeding 
task to waft by referring to the graph; and 

a means for removing the token from the gate node after the signal for beginning the succeeding task 
is transmitted. 

An embodrnrtent of the invention will now be described in detail with reference to the following figures. 
Figure 1 is a system configuration of an embodiment according to the invention. 
Figure 2 is a schematic view of the flow of the process. 

Figures 3A, 3B and 3C are diagrams illustrating the description of an example of a mutual exdush^e control 
program according to the prior art 

Figure 4 is a diagram illustrating an example of execution of a Petri-Net 

Figure 5 is a diagram illustrating a model of mutual exclusive control employing the Petri-NeL 

Figure 6A and 6B are diagrams illustrating a deadlock that would occur if a conventional Petri-Net were 
executed to perform the mutual exclusive control. 

Figure 7 is a diagram illustrating a process flow graph. 

Figure 8 is a diagram illustrating a process flow graph and a task program. 

Figure 9 is a diagram illustrating a resource management graph. 

Figure 1 0 is a flowchart of processing procedures for generating a resource management graph. 
Figure 1 1 is a flowchart of processing procedures for generating a process resource graph. 
Figure 12 is a diagram illustrating a process resource graph. 

Figure 13 is a flowchart of processing procedures for generating a union graph of a program flow graph 
and a resource management graph. 

Figure 14 is a diagram illustrating a flow of process that causes a deadlock. 

Figure 15 is a diagram showing a union graph representation of the contents of Figure 14. 

Figures 16A, 16B, 16C, 16D. 16E, 16F are diagrams showing an example of execution of the process re- 
source graph of Figure 12. 

Figure 1 7 is a diagram showing an example of hardware configuration of a mutual exclusive control system. 

Figure 18 is a diagram showing the process resource graph corresponding to Figure 6. 

Figures 19A, 198. 19C and 19D are diagranrts showing an example of execution of the process resource 
graph of Figure 18. 

Figure 1 is a system configuration of an embodiment of the invention. Now. steps SI - S8 in the figure are 
described in order. 

(a) Creatbn of a process flow graph (step SI ) 

A user creates a process flow graph representing an event driven process with a task as a unit of process. 
The created process flow graph is equivalent to a restricted Petri-Net graph with a safe and active nature (with- 
out multibranch nor self loop). Refer to the TVIathematical Representation" for the definition of the process flow 
graph. 

As methods for creating the process flow graph, there are a method in which it is described with graphical 
symbols by using a graphics editor, and converted to a text representation, and a method in which it is directly 
described with character codes by using a text editor. The created process flow graph is also called a process 
flow program. 

In the embodiment the user describes it interactively with a graphics editor. Figure 7 shows a graphical 
representation of the process flow program. A unit of control on the process flow graph is called a task, which 
corresponds to a program file (see Figure 8). 

An example of execution according to the definition of the process flow graph is explained by referring to 
Figure 7. A token is generated in a condition gate Ci or C4. In a case where the token is generated in the con- 
dition gate C,, the token moves to task places T, and T2 where tasks Ti and T2 are executed by using resources 
Ra and Rb- When both tasks T, and T2 are completed, the token moves to a task place T3 according to the 
condition of the condition gate C2. The task T3 is executed by using the resource Rg. Then, when the task T3 
is completed, the token moves from the place T3 to the conditton gate C3, and is removed. In a case where 
the token is generated in the condition gate C4. the token moves to a task place T4 where the task T4 executed 
by using the resource Ra. When the task T4 is completed, the token moves to a task place T5 according to the 
condition of the condition gate C5. The task Tb is executed by using the resources Ra and Rg. Then, when the 
taskTs is completed, the token moves from the place T5 to the condition gate C3, and is removed. This example 
of execution does not contain the mutual exclusive resource control. Here, the condition gate corresponds to 
the transition in the Petri-Net. but definitely differs from the transition in the point that it allows a token to be 
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assigned to itself. This will be explained in detail later. 

Atext representation of the process flow program is created in the form of intermediate codes of the process 
flow graph. It is equivalent to the graphical representation, and they can be converted to each other. In the 
following, the text representation of the graph is also called the intenmediate codes. 
5 The fonfnat of the intermediate codes of the process flow graph is as follows: 

Condition gate: 

Input place(p input place ...)/ 
Output place (, output place ...) 
The intermediate codes of the embodiment in Figure 7 is as follows. 
10 Ci:/Ti.T2 
C2:Ti,T2n-3 
CarTy 
C4 : /T4 
CsiT/Ts 
IS Ce : Tg/ 

(b) Generation of resource management graph (steps S2 and S3) 

A resource management graph is generated from the process flow graph and the task program. Resource 
20 names of critical resources necessary for the tasks are extracted from the task programs, thereby generating 
a list of them. As shown in Figure 8, when the task program is described in a text, the critical resources described 
therein are described by logical symbols of the resources. logical numbers of the resources, or logical names 
of the resources. A resource management graph is generated from the process flow graph and the list which 
extracted the resource names. Figure 9 shows a resource management graph generated from the process flow 
25 graph of Figure 7 and the resource name list of the critical resources necessary for the tasks. 

It should be noted that, as shown in Figure 8. the user is never required to pay attention to resource man- 
agement by using semaphores or the like, in creating a program of a process flow graph describing connection 
between tasks, or a task program describing an individual task. 

In the embodiment, the program is described with an object oriented language by using a text editor in the 
30 following format. 

Logical name of resource : command 

A list is created that extracts the names of the critical resources used by the task from the logical names 
of critical resources in the task programs. A resource management graph is generated from the list and the 
process flow graph. 

35 If the form at of the intermediate codes of the resource nnanagement graph is made the same as that of 

the intermediate codes of the process flow graph, the intermediate codes for the embodiment of Figure 9 is 
as follows: 

Ci : /Ra. Rb 

40 C3 : Rb/ 

C4:/Ra 
C5 : Ra/Rai Rb 
Os : Rai Rb/ 

Figure 10 is a flowchart illustrating an algorithm for generating such intermediate codes from the process 
45 flow graph with the resource name list If all resources are critical, the resource name list may be created by 
autonr»atically extracting all resource names contained in the task program. The user may create the resource 
name list by specifying the critical resource names. 

(c) Generation of process resource graph (steps S4, S5, and S6) 

50 

The process for generating the process resource graph is shown in Figure 11 as a flowchart. Explanation 
is made by referring to the flowchart The process flow graph and the resource management graph are loaded 
(steps 111 and 112). from which a graph of union is generated (step 113). 

Figure 12 shows graph of union generated from the process resource graph of Figure 7 and the resource 
55 management graph of Figure 9. 

If the form at of the intermediate codes of the unfon graph is made the same as that of the intermediate 
codes of the process flow graph, the representation of the union graph of Figure 12 is as follows: 

Ci ; fTu T21 Ra» Rb 
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^2 : T^, T2, Rai RfiTa, Rb 

C4 : /T4, Ra 
Cs : T4, Ra/T 6, Ra, Rb 
5 Ce : T5, Ra, Rb/ 

Figure 13 is a flowchart illustrating an algorithm for generating such intermediate codes from the process 
flow graph and the resource management graph. That is, it shows the step 113 of Figure 11 in detail. 

By the way, if the union graph thus generated is unconditionally regarded as a process resource graph as 
it is, a deadlock may be caused. 
10 Figure 14 shows a case where a deadlock is caused. In the initial state, a token is in the condition gate 

Cv The deadlock is caused t>ecause the task T^ should be executed while using the resource Ra, and the task 
T2 should be executed while using the resources Ra and Rb. 

The embodiment uses a graph that causes no deadlock of a comnran connection graph as the process 
resource graph. When execution is performed according to this, it is possible to simultaneously perform the 
IS control of an event driven process and the mutual exclusive resource control. If the common connection graph 
causes a deadlock, it is reported to the user. 
* In the embodiment, the deadlock that may be caused in the common connection graph is displayed (step 

115) after checking a deadlock at the time when the common connection graph is generated from the process 
flow graph and the resource management graph (step 114). 
20 Figure 1 5 is a representation of Figure 14 in the form of a union graph. As shown in Figure 1 5, a deadlock 

occurs in a case where a condition gate and a resource place are connected in duplicate. It is sufficient to check 
whether or not the generated union graph has a resource connected to one condition gate in duplicate, and to 
point it out to the user if there is one. If no deadlock occurs, the union graph is used as the process resource 
graph as it is (step 116). 

25 Here, the deadlock referred to herein is not caused from the graph representation described with respect 

to Figure 6 and from the responsibility of the system that performs control according to it As described later, 
occurrence of the deadlock as in Figure 6 is avoided according to the invention. The deadlock displayed in 
step 11 5 of Figure 11 is caused from the program structure itself, which should be avoided on the responsibility 
of the user (step 117). 

30 The process resource graph is a bipartite directed graph, nodes of which are event places and condition 

gates, and arcs of which are input functions and output functions. Marking means to assign tokens to the task 
places, the resource places, or the condition gates of the process resource graph. In addition, at nnost one token 
can exist in one task place, one resource place, or one condition place. In a conventional Petri-Net, a token is 
not assigned to a condition gate, while assigned in the process resource graph. Refer to the "Mathematical 

35 Representation" for the definition of the process resource graph. 

In the union graph or the process resource graph shown in Figure 1 2. every task node is arranged in parallel 
with a resource node. However, sonr>e tasks never access the critical resource. Of course, no resource node 
is arranged in parallel with such a task node (see Figure 1 8). 

40 (d) Execution of process resource graph (steps S7 and S8) 

The process resource graph is converted into codes for a controller that performs event driven control to- 
gether with the mutual exclusive control of sequentially available resources, and loaded in the memory or ROM 
of a controller to be executed (such as a computer or a programmable logic controller). When this graph is 

45 executed, the mutual exdush^e control and the event driven process control are simultaneously performed. 
For example, a node (an event place or a condition gate) of a process resource graph is implemented in a menv 
ory as a data structure, and the connection between elements is represented by pointers. Information relating 
to presence of a token is stored in the data structure. The method itself for generating or erasing a token is 
implemented similarly to the system of the atx>ve reference (2), and is not described in detail herein. 

50 The conditfons for transferring the token presented by the invention are strictly represented by equations 

(1) and (2). which will be represented by words as follows: 

(I) As soon as the beginning of execution of a task is instructed, a token is assigned to the place (node) 
of the task and the resource place in parallel with the place. That is, according to the invention, different 
from the conventional Petri-Net, the token placed in the resource place indicates that the resource is ap- 

55 propriated by the task being executed. 

(II) If there are tasks controlled in parallel, the tokens are transferred to a succeeding condition gate at the 
time when execution of all the tasks is completed. 

(III) While a token is assigned to at least one of the task places immediately after the condition gate and 



7 



EP 0 383 506 B1 



the resource place in parallel with the task places, the beginning of the execution of the succeeding task 
is caused to wait by keeping the token in the condition gate. 

Figure 16 shows the execution according to the definition of the process resource graph of Figure 12 as 
an example of execution control. In Figure 12, there Is a case where a token is generated first in the condition 

5 gate Ci, and a case where it is generated first in the condition gate C4. This example of execution treats the 
case where the token is generated first in the condition gate C^, The token is generated in the condition gate 
Ci (Figure 16A). As shown, even if it is necessary to execute the task Ti and T2, tokens are not immediately 
placed in the places Ti and T2. First, the token is assigned to the condition gate Ci. The token moves from the 
condition gate to the task places Ti and T2, and the resource place Ra and Rb according to the transfer 

10 condition equation (1) (Figure 16B). At this rrKMnent, even if a token is assigned to another conditton gate, the 
transfer condition equation (1) is not satisfied because a token Is assigned to the resource places Ra and Rb. 
Therefore, the token does not move, and a new task other than T^ and T2 Is not executed. When both tasks 
Ti and T2 are completed, the token nrw>ves from the task places Ti and T2 and the resource places R^ and Rq 
to the condition gate C2 according to the transfer condition equatk>n (2) (Figure 16C). In addition, the token 

15 moves from the conditton gate C2 to the task place T3 and the resource place Rb (Figure 1 6D). At this moment 
It is assumed that a token is generated in the condition gate C4. The execution of the task T4 can now be started. 
That is. t>ecause there is no token in the resource place Ra* the transfer conditton equation (1) is satisfied so 
that the token is transferred to the task place T4 and the resource place Ra (Figure 1 6E). Therefore, the exe- 
cution of the taskTs using the resource Rb and the execution of the task T4 using the resource Ra are performed 

20 independently. When T4 is completed, the token moves from the task place T4 and the resource place Ra to 
the condition gate (Figure 16F). Even if a token is assigned to the condition gate Cg, the token is not trans- 
ferred from the condition gate Cs to the task place T5 and the resource places Ra and Rb. because another 
token already is assigned to the resource place Rb and the transfer condition equation (1) is not satisfied. That 
Is. the task T5 Is not executed. When the task T3 Is completed, the token moves from the task place T3 and the 

25 resource place Rb to the conditton gate C3 according to the transfer condition equation (2), and is removed. 
Therefore, the task T5 becomes executable. 

As seen from the example of Figure 12, the process resource graph becomes a graph having self loops 
with respect to the resource places Ra and Rb. When It Is regarded as a restricted Petri-Net with a safe and 
acth^e nature, if tasks attempt to sequentially and immediately use the same resource, a deadlock occurs. For 

30 example, in Figure 12, if, the task T5 attempts to perform execution using the resources Ra and Rb after the 
task T4 completes executfon using the resource Ra, a graph of a self loop with respect to the resource Ra is 
constituted, and a deadlock Is caused because the transfer condition equation (O), which is described later, 
is never satisfied. 

This will be further described. First, it should be noted that the graph representation like Figure 12 itself 

35 is novel. (Differences from a conventk3nal Petri-Net will be explained in nrK>re detail by comparing Figures 6 
and 18 later). Then, It is assumed that a token is placed in a place of a held resource, but not placed in a condition 
gate In an embodiment In this example, a token Is placed in the places T4 and Ra during execution of the task 
T4. Then, even If the control system attempts to begin the execution of the task T5, that is, even if it attempts 
to transfer a token from the place T4 to the place T5 and the places Ra and Rb. it is impossible to transfer the 

40 token to the place T5 because a token is already assigned to the place Ra- Then, as long as the token cannot 
move to the place T5, the token in the place Ra cannot be removed. 

If a token is caused to exist in a condition gate as defined for the process resource graph, deadlock as in 
the restricted Petri-Net with safeness and llveness never occur. That is. in the above example, at the time when 
the execution of the task T4 is completed, a state where^no token Is assigned to the place Ra appears by re- 

45 moving the token from places T4 and Ra, and by generating a token in the condition gate Cg, so that the token 
can be transferred from the condition gate Cg to the places Tg. Ra. and Rb- That is. the execution of the task 
T5 can be started. The significance of assigning a token to a conditton gate lies in this point 

The executable codes of the process resource graph are loaded In the memory or ROM of the controller 
to be executed. Here, sequentially available resources to be controlled are ones that are controlled by a com- 

50 puter or a programmable logic controller (PLC). These resources include not only those actually contained in 
the controller, but also those that can be controlled through communication or the like. The invention performs 
the mutual exclusive resource control together with the event driven process control for the sequentially avail- 
able resources, which are the objects of the control, based on the executable codes of the process resource 
graph. Figure 17 shows an example of hardware configuration of a system that performs such control by load- 

55 ing the executable codes of the process resource graph. In this example, the production apparatus 1, 2, 3, ... 
are the critical resources. A task using such apparatus is described in a task program as shown in Figure 8. A 
signal Instructing beginning of the execution of the program and an end signal notifying completion of the exe- 
cution of the program are transferred between the PLC and the production apparatus through a digital in- 

8 
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put/output interface or a communication interface. The completion of execution of a task is detected by sending 
a signal from the production apparatus to the PLC. Otherwise, the PLC may monitor a state of the production 
apparatus to detect change of the state to the completion state. 

In addition, a task program may be stored in the production apparatus, or may be stored in the memory 
5 of the PLC for sequential transfer of instructions from the PLC to the production apparatus. 

Finally, as a summary, the process resource graph that is a result of representation of the flow of process 
as shown in Figure 6 according to the invention is shown in Figure 18. and an example of its execution is shown 
in Figures 19A through 19D. 

The graph of Figure 18 differs from that of Figure 6 significantly in the following points. Even when two 
10 consecutive tasks (for example. P2 and P3) use a resource (in this case. PJ, the resource place is connected 
to each of them in parallel. Relations between the input and the output are revereed. For example, in Figure 
6. the place is connected to the input of the transition ti. while, in Figure 18, it is connected to the output of 
the condition gate C^. 

Now, an example of execution is discussed wherein a token is transferred according to the invention. First. 
15 It is assumed that tokens are generated in the condition gates Ci and C4 (Figure 19A). If there is no token in 
either of the resource places P, and Py. the token can be transferred from the condition C^ the places P2 and 
Px. while from the condition gate C4 to the places P5 and Py (Figure 19B). That is, the execution of the tasks 
P2 and P5 is started. Then, it is assumed that the execution of the task P2 is completed. At this time, the control 
system erases the tokens In the places P2 and P^. and generates a token in the condition gate C2 (Figure 19C). 
20 At the moment, because a token still is assigned to the place Py. it is impossible to transfer the token to the 
place P3. Thus, in the process A, the token remains in the condition gate C2. and waits for release of the re- 
source Py. Then, when the control system receives an end signal of the task P5, it removes the token from 
places Ps and Py, and generates a token in the condition gate Cs (Figure 19D). The control system may transfer 
the token to the places P3. and Px and Py. or may transfer the token to the places Pg and P^. That is. it can 
25 instruct the beginning of the executfon of the task P3 or Pe- As described, deadlock as in Figure 6 never arises. 

As above, the inventton is explained by referring to the embodiment. Other modifications is possible. For 
example, although, in the above embodiment, the process flow graph and the resource management graph 
are generated in a form of intermediate codes, and the process resource graph is once generated in the form 
of intermediate codes and then converted into executable codes, the form of their representation is not restrict- 
so ed to a specific one because it is sufficient for these graphs to generate in a memory representations equivalent 
to the ones represented in the drawings. 

A description is given according to the definition of the process flow theory in the following. The process 
flow graph Gpp is: 

GpF = (T. C. It. Ot. \x) 

35 wherein: 

T = {Ti, T2 Tm}, M > 0 Set of task places 

C = {Ci, C2 CJ. L > 1 Set of condition gates 

T n C = (|> The set of the task places and the set of the condition gates are disjoint 
It : T -> C Input function from a task place to a condition gate 
40 Ot : C T Output function from a condition gate to a task place 
H :T {0, 1} Marking functton of a task place 

A transfer conditton equation of a token from a task place T| to To in respect to an arbitrary conditran gate Ck 
at an arbitrary time t is: 

45 



ml m2 
#(Ti, To) (t) = n n (TiCt)) _ n (To(t)) .... (0) 
1=1 0=1 

wherein, ml > 0. m2 > 0 

A new marking at time t+1 is: in the task place Ti, 

^ (n(t + 1)) = M (Ti(t)) - #(Ti, To) (t) i = 1 ... ml 

in the task place To, 

(To(t + 1)) = n (To(t)) + #(Ti. To) (t) o = 1 ... m2 
9 
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A token is generated in a case where there is no input function It in the condition gate C^, and the right hand 
terms of the transfer condition equation are made: 



n (Ti(t)) = 1 
i=l 

10 A token disappears in a case where there is no output function 0|- in the condition gate Ck. and the right hand 
terms of the transfer condition equation are made: 



15 



m2 

n VI (To(t)) = I 
o=l 



20 The process resource graph is described according to the definition of the graph theory. The process resource 
graph Grr is: 

GpR = (T_R, C. It . Irp Or . Op.pT - |tR - pc) 

wherein, 

T = {Ti, T2 Tm), M > 0 Set of task places 

25 R = {Ri, R2, — , RfJ. N ^ 0 Set of resource places 
C = {Ci, C2, .... CJ. L > 1 Set of condltton gates 

T n R n C = <|> The set of the task places, the set of resource places and the set of the condition gates are 
disjoint 

It : T C Input function from a task place to a condition gate 
30 Ir : R C Input function from a resource place to condition gate 

It ^ = <^ '^^^ input function It and the input function Ir are disjoint. 

Or : C T Output function from a condition gate to a task place 

Or : C -f R Output function from a conditton gate to a resource place 

Ot n Or = <|t The output function Or and the output function Or are disjoint 
3S : T -> {0. 1} Marking function of the task place jir : R -> {0, 1} Marking function of the resource place 
: C {0, 1} Marking function of the condition gate 

Ht kiR ^ Mc = ♦ The marking function jit . the marking function hr, 

and the marking function disjoint 

A transfer condition equation of a token from an arbitrary condition gate Ok to event places T and R at an 
40 arbitrary time t is: 



m n 
#(C, P) (t) = (n vi (Ti(t)) _ n KJi (Ri(t)) _ [x (Ck(t)) 
i=l 3=1 



(1) 



wherein, m > 0, n > 0 

A new marking at time t+1 is: tn the condition gate Ck, 

|i(CK(t+1)) = ^(CK(t)) - #(c,p)(t) 

55 in the task place T, 

^(Ti(t + 1)) = MCn(t)) + #(c,p)(t)i = 1...m, 

in the resource place R, 

(Fg{t + 1)) = M (Ri(t)) + #(c, p) (t) j = 1 ... n. 
10 
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A transfer condition equation of a token to an arbitrary condition gate Ck from event places T and R at an ar- 
bitrary time t is: 



10 



m n 

#(c, P) (t) = (n ^ (T.{t)) _ n (i^(t)) ^ ^JL ((^ (t)) 

i=l j=l 



(2) 



wherein, m > 0, n > 0 
15 A new marking at time t+1 is: in the condition gate Ck, 

(CK(t + 1)) = ^ (Ck (t)) + #{p. c) (t) 

in the task place T, 

(Ti(t + 1)) = H (T,(t)) - #(p. c) (t) i = 1 ... m, 

in the resource place R, 
20 H(R|(t+ 1)) = ^(R,(t)) - #(p, c) (t)j = 1 ... n. 

A token is generated in a case where there is no input function ly and Ir in the condition gate C^, and the right 
hand terms of the transfer condition equation (2) are made: 

m n 

25 



(n (Ti(t)) _ n (R (t)) = 1 
i=l i=l 



30 A token is removed in a case where there is no output function Oy and Or in ttie condition gate Ck, and the 
right hand tenns of the transfer condition equation (1) are made: 



(n |ji (T(t)) _n ix (R(t)) = 1 
i=l j=l 

40 The invention enables a user to perform the mutual exclusive control for sequentially available resources 

together with the event driven control only by describing an event driven control (the process flow graph and 
the task program). The invention automatically performs programming and execution for management of re- 
sources in a process, for which a programmer was responsible, and removes the burdens of preventing errors 
in a resource management program from the programmer, and removes the burden of executing the program 

45 from the operator. 

In additk>n, the inventton provides the advantage that a deadlock which may conventionally occur in a Petri- 
Net is avoided by assigning a token to a condition gate. 



50 Claims 



1. A method for mutual exdushre resource control comprising steps of: 

(a) generating a graph and retaining the graph in a storage apparatus, the graph comprising nodes to 
which tasks included in a process flow and a critical resource, which may be appropriated by at least 
one of the tasks, are mapped, nodes of tasks executed sequentially being arranged in series, nodes 
of tasks executed in parallel being arranged in parallel with each other, a node of critical resource being 
arranged in parallel with every node of the task that may appropriate the critical resource; and 

(b) each time a signal for beginning execution of a task is transmitted, generating a token in the node 
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of the task and the critical resource node in parallel therewith; and 

(c) when the end of execution of the preceding task in the process flow is detected, referring to said 
graph; and causing the transmission of a signal for beginning execution of the immediately succeeding 
tasks to wait while a token is assigned to at least one of the immediately succeeding task node and 
the critical resource node arranged in parallel therewith. 

A method as claimed in Qaim 1. comprising in said step (a), providing a gate node in said graph at a lo- 
cation where nodes of tasks executed sequentially are connected: 

in said step (b). renrK)ving tokens from a task node and a critical resource node arranged in parallel 
with it. each time the completion of the execution of the task is detected, generating a token in a gate 
node when completion of tasks corresponding to all the task nodes arranged immediately before the gate 
node is detected, then, referring to said graph, and causing the transmission of a signal for beginning the 
execution of a succeeding task to wait while a token is assigned to at least one of the task node and the 
critical resource node in parallel therewith arranged immediately after the gate node; and removing the 
token from said gate node after the transmission of the signal for beginning the execution of said suc- 
ceeding task. 

A method as claimed in daim 2. wherein said step (a) comprises; 

(a 1 ) creating a process flow graph consisting of nodes of taslcs included in the process flow and nodes 
of gates; 

(a 2) creating a resource management graph consisting of nodes of critical resources, which may be 
appropriated by at least one of said tasks, and nodes of said gates; and 

(a 3) creating a graph of union in which said process flow graph and said resource management graph 
are overlapped with nodes of said gates common, and retaining the graph of union in a storage device. 

Amethod as daimed in Claim 3, wherein, after the unfon graph of the process flow graph and the resource 
graph are created in said step (a 3). said unk>n graph is checked to see whether or not there is a location 
where a deadlock occurs, and displaying the union graph to a user if so. 

A method as daimed in Claim 4, wherein, 

in step (a 1). the process flow graph is outputted in the form of intermediate codes; 

in step (a 2). the resource management graph is outputted in the form of intermediate codes; 

in step (a 3), the union graph is once outputted in the form of intermediate codes, which are con- 
verted into executable codes and then retain in a storage device; and 

in step (b). mutual exdusive contrbl is performed based on said execution codes. 

A system for mutual exclusive resource control comprising a storage apparatus retaining a graph in which 
tasks induded in a flow of process, and critical resources, which may be appropriated by at least one task, 
correspond to nodes, nodes of tasks sequentially executed being arranged in series, nodes of the tasks 
executed in parallel being arranged in parallel with each other, a node of a critical resource being arranged 
in parallel with every node of tasks that may appropriate the critical resource; 

means for generating tokens in a node of a task and a node of a critical resource arranged in parallel 
with the task node in said graph each time a signal for beginning execution of the task is transmitted; 

means for referring to said graph when the end of execution of a preceding task in the process flow 
is detected, and causing the transmission of a signal for beginning execution of the immediately succeed- 
ing tasks to wait while a token is assigned to at least one of the immediately succeeding task nodes and 
the critical resource node arranged in parallel therewith. 

A system as claimed in Claim 6 wherein a node of a gate Is arranged in the graph at a location connecting 
the nodes of the taslcs with each other, the system comprising means for removing the tokens assigned 
to the node of the task and to the node of the critical resource arranged in parallel with the task node each 
time the end of the executk>n of the task is detected; 

means for generating a token in a gate node, when completton of execution corresponding to all 
the task nodes arranged immediately before the gate node; and 

means for erasing the token in the gate node after the signal for beginning the succeeding task is 
transmitted. 
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Patentanspruchia 

1. Ein Verfahren zur gegenseitig ausschlie&enden Betriebsmittelsteuerung, das folgende Schritte umfa&t 

(a) Erzeugen eines Graphen und Festhalten des Graphen in einer Speichervorrichtung, wobei der 
Graph Knoten umfaat, denen Tasks, die in einen Proze&ablauf integriert sind, und ein kritisches Be- 
triebsmrttel, das sich mindestens einer der Tasks aneignen kann, zugeordnet sind, die Knoten von se- 
quentiell ausgef uhrten Tasks in Reihe angeordnet sind, die Knoten von parallel ausgefQhrten Tasks par- 
allel zueinanderangeondnet sind und ein Knoten des kritischen Betriebsmittels parallel zu jedem Kno- 
ten des Tasks angeordnet ist, der sich das kritische Betriek>smittel aneignen kann; und 

(b) bei jeder Ubertragung eines Signals fur den Beginn der Ausf uhrung eines Tasks Erzeugen etnes 
Balkens in dem Knoten des Tasks und des dazu parallelen Knotens des kritischen Betriebsmittels; und 

(c) bei der Erkennung des Endes der Ausf uhrung des vorherigen Tasks im ProzeBablauf Zurflckgreifen 
auf den Graph; und Veranlassen, da& die Obertragung eines Signals fur den Beginn der Ausfuhrung 
der unmittelt>ar nachfblgenden Tasks wartet, wahrend ein Balken mindestens einem der unmlttelbar 
nachfblgenden Taskknoten und dem parallel dazu angeordneten Knoten des kritischen Betriebsmittels 
zugeordnet ist 

2. Ein Verfehren gem3& Anspruch 1, umfassend in Schritt (a) das Vorsehen eines Gatterknotens an einer 
Stelle des Graphen, an der Knoten der Tasks, die sequentiell ausgef uhrt werden, verfounden sind; 

in Schritt (b) das Entfernen von Balken von einem Taskknoten und einem parallel dazu angeordneten kri- 
tischen Betriebsmittelknoten bei jeder Erkennung der Vollendung der Ausfuhrung des Tasks, das Erzeu- 
gen eines Balkens in einem Gatterknoten bei der Erkennung der Vollendung von Tasks, die zu alien Task- 
Knoten gehoren, die unmlttelbar vor dem Gatterknoten angeordnet sind, und dann das ZuruckgrBifen auf 
den Graph und das Veranlassen der Obertragung eines Signals zum Beginnen der Ausfuhrung eines 
nachfolgenden Tasks zum Warten, wahrend ein Balken mindestens einem der Taskknoten und dem par- 
allel dazu unmlttelbar nach dem Gatterknoten angeordneten kritischen Betriebsmittelknoten zugewiesen 
wird; und das Entfernen des Balkens von dem Gatterknoten nach der Obertragung des Signals zum Be- 
ginnen der Ausfuhrung des nachfblgenden Tasks 

3. Ein Verfahren gemaft Anspruch 2, wobei der Schritt (a) umfafifc 

(a 1) das Erstellen eines ProzeBablaufgraphen. bestehend aus Knoten von Tasks, die in dem Praze&- 
ablauf enthalten sind, und aus Knoten von Gattern; 

(a 2) das Erstellen eines Betriebsmittelverwaltungsgraphen, bestehend aus Knoten kritischer Betriebs- 
mittel, die sich mindestens einer der Tasks aneignen kann, und aus Knoten der Gatter; und 
(a 3) das Erstellen eines Vereinigungsgraphen, in dem der ProzeBablaufgraph und der Betriebsmittel- 
verwaltungsgraph mit Knoten gemeinsamer Gatter uberlappt sind, und das Festhalten des Vereini- 
gungsgraphen in einer Speichervorrichtung. 

4. Ein Verfahren gennSfi Anspruch 3, bei dem nach dem Erstellen des Vereinigungsgraphen aus ProzeBab- 
laufgraph und Betriebsmittelgraph in Schritt (a 3) der Vereinigungsgraph daraufhin uberprQft wird, ob es 
eine Stelle gibt, an der es zu einer Blockierung kommt, und wenn ja, der Vereinigungsgraph einem Be- 
nutzer angezetgt wird. 

5. Ein Verfahren gem3& Anspruch 4, bei dem 

in Schritt (a 1) der ProzeBablaufgraph in Form von Zwischencodes ausgegeben wird; 

in Schritt (a 2) der Betriebsmittelverwaltungsgraph in Form von Zwischencodes ausgegeben wird; 

in Schritt (a 3) der Vereinigungsgraph einmal in Form von Zwischencodes ausgegeben wird, die in aus- 

fuhrt>are Codes umgewandelt und dann in einer Speichervonichtung festgehalten werden; und 

in Schritt (b) die gegenseitig ausschlieSende Steuerung auf der Grundlage der Ausf uhrungscodes durch- 

gef uhrt wird. 

6. Ein System fur eine gegenseitig ausschiiefiende Betriel>smittelsteuerung. die eine Speichervonichtung 
umfaBt, die einen Graph enthalt, in dem Tasks, die in einem ProzeOablauf enthalten sind, und kritische 
Betriebsmittel, die sich mindestens ein Task aneignen kann, zu Knoten gehoren, Knoten von Tasks, die 
sequentiell ausgefuhrt werden. in Reihe angeordnet sind, Knoten der Tasks, die parallel ausgef uhrt wer- 
den, parallel zueinander angeordnet sind und ein Knoten eines kritischen Betriebsmittels parallel zu jedem 
Knoten von Tasks angeordnet ist, die sich das kritische Betriebsmittel aneignen konnen; 

ein Mittel zur Erzeugung von Balken in einem Knoten eines Tasks und in einem Knoten eines kritischen 
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Betriebsmittels» der parallel zu dem Taskknoten in dem Graph angeordnet ist, bei jeder Obertragung eines 
Signals zum Beginnen eines Tasks; 

ein Mittel zum Zuruckgreifen auf den Graph bei der Erkennung des Endes der Ausfuhrung eines vorher- 
gehenden Tasks in dem ProzelUiblauf und Veranlassen der Obertragung eines Signals zum Beginnen der 
Ausfuhrung der unmittelbar nachfolgenden Tasks zum Warten, wahrend ein Balkan mindestens einem der 
unmittelbar nachfalgenden Taskknoten und dem parallel dazu angeordneten kritischen Betriebsmittelkno- 
ten zugewiesen wird. 

7. Ein System gemaR Anspruch 6, in dem ein Knoten eines Gatters an einer Stelle des Graphen angeordnet 
ist die die Knoten der Tasks miteinander verbindet, wobei das System umfa&t ein Mittel zum Entfernen 
der Balken, die dem Knoten des Tasks und dem parallel zu dem Taskknoten angeordneten Knoten des 
kritischen Betriebsmittels zugewiesen sind, bei jeder Erkennung des Endes der Ausfuhrung des Tasks; 
ein Mittel zum Erzeugen eines Balkans in einem Gatterknoten, wenn die Ausfuhrung, die zu alien unmit- 
telbar vor dem Gatterknoten angeordneten Taskknoten gehdrt, beendet tet; und 

ein Mittel zum Loschen des Balkans in dem Gatterknoten nach der Obertragung des Signals zum Begin- 
nen des nachfolgenden Tasks. 

Revendications 

1. Pfoc^6 pour la convnande de ressource mutuellement exclusive comprenant les stapes consistant d : 

(a) gSn^rer un graphe et conserver le graphe dans un appareil de memorisation, le graphe comprenant 
des noeuds sur lesquels des tdches comprises dans un dSroulement de processus et une ressource 
critique, qu'au moins une des tSches peut s'approprier, sont planif i6es, les noeuds des tSches ex^cu- 
t^es s^quentiellement 6tant agenc^s en series, les noeuds de tdches ex^cut^es en parall&le 6tant 
agenc6s en parall&le les uns avec les autres. un noeud de ressource critique Stant agenc6 en parall^le 
avec chacun des noeuds de la tdche qui peut s'approprier la ressource critique, et 

(b) ^ cheque Ibis qu'un signal de d^but d'ex^cution d'une tache esttransmis, g^n^rer un jeton dans le 
noeud de la tdche et le noeud de ressource critique en parall&le avec celui-ci, et 

(c) lorsque la fin de Tex^ution de la tdche pr^dente dans le d^roulement du processus est dStect^e, 
se rSf^rer audit graphe, et provoquer la transmission d'un signal de d6but d'ex6cution des tSches im- 
m^diatement suivantes en attente alors qu'un jeton est affects d au moins un parmi le noeud de t§che 
suivant imm^iatement et le noeud de ressource critique agenc6 en parall^le avec celui-ci. 

2- Pn>c6d6 selon la revendication 1. comprenant dans ladite 6tape (a), Tapprovisionnement d'un noeud de 
porta dans ledlt graphe ^ un emplacement ou les noeuds des tdches ex^cut^es s6quentiellement sont 
relics : 

dans ladite 6tape (b), la suppression des jetons provenant d'un noeud de tSche et d'un noeud de ressource 
critique agenc6 en paralldle avec celui-d. d chaque fois que Tach^vement de Tex^cution de la tSlche est 
detects, la generation d'un jeton dans un noeud de porte lorsque Tachdvement des tdches correspondant 
k tous les noeuds de t§che agenc^s immediatement avant le noeud de porte soit detects, puis, la consul- 
tation dudit graphe et le dedenchement de la transmission d'un signal de debut d'executk)n d'une tdche 
suivante en attente alors qu'un jeton est affecte d au moins un panmi les noeuds de tdche et le noeud de 
ressource critique en paralieie avec celui-ci agence immediatement apres le noeud de porte, et la sup- 
pression du jeton dudit noeud de porte apres la transmission du signal de debut d'execution de ladite tdche 
suivante. 

3. Precede selon la revendication 2, dans lequel ladite etape (a) comprend, 

(a 1) la creation d'un graphe de deroulement de processus consistant en des noeuds de tdches indus 
dans le deroulement de processus et des noeuds de portes, 

(a 2) la creation d'un graphe de gestk>n de ressource consistant en des noeuds de ressources critiques, 
qu'au moins une desdites tdches peut s'approprier, et de noeuds desdites portes, et 
(a 3) la creation d'un graphe d'union dans lequel ledit graphe de deroulement de processus et ledit gra- 
phe de gestion de ressource se recouvrent avec des noeuds desdites portes en commun, et la conser- 
vation du graphe d'union dans un dispositif de memorisation. 

4. Procede selon la revendication 3, dans lequel apres que le graphe d'union du graphe de deroulement de 
processus et que le graphe de ressource soient crees dans ladite etape (a 3). ledit graphe d'union est 
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vSrifid pour voir s*n existe ou non un emplacement ou se produit un btocage, et en affichant le graphe 
d'union ^ un utiltsateur si c'est le cas. 

Pioc6d6 selon la revendication 4, dans lequel, 

dans r^tape (a 1 ). le graphe de d^roulement de processus est sorti sous ia forme de codes interm6dlaires, 

dans r^tape (a 2). le graphe de gestlon de ressource est sorti sous la fbnme de codes interm^diaires, 

dans r6tape (a 3), le graphe d'union est sorti une fois sous la forme de codes interm6dialres, qui sont 

convertis en codes ex^cutables puis conserve dans un dispositif de m6nrK>risation, et 

dans rstape (b), la oommande nmituellement exclusive est effectu6e sur la base desdits codes d'ex6cu- 

tion. 

Syst^me destine ^ la commando de ressource mutuellement exclusive comprenant un apparell de me- 
morisation conservant un graphe dans lequet les tSches induses dans un d^roulement de processus, et 
des ressources critiques, qu*au moins une tSche peut s'approprier, correspondent k des noeuds, les 
noeuds des tSches ex6cut6es s^uentiellement ^tant agenc6s en series, les noeuds des tdches ex6ou- 
t6es en parall^le 6tant agenc6s en parall^le les uns avec les autres, un noeud d'une ressource critique 
dtant agenc^ en parall^le avec chaque noeud des tSches qui F>euvent s'approprier la ressource critique, 
un moyen destin§ k g6n6rer des jetons dans un noeud d'une tSche et un noeud d'une ressource critique 
agenc^ en parali^le avec le noeud de tdche dans ledit graphe d chaque fois qu'un signal de d^but d'ex^ 
cution de la tdche est transmis, 

un moyen pour se r6f6rer audit graphe lorsque la fin de fex^cution d'une tdche prdc^ente dans le d6- 
roulement de processus est d6tect6e, et pour provoquer la transmission d'un signal de d6but d'exScution 
des tdches imm^diatement suivantes en attente alors qu'un jeton est affects ^ au moins un parmi les 
noeuds de tSche imm^iatement suivants et le noeud de ressource critique agenc6 en parallSle avec 
ceux-ci. 

Syst^me selon la revendication 6 dans lequel un noeud d'une porte est agenc6 dans te graphe d un em- 
placement reliant les noeuds des tdches entre elles, le syst^me comprenant un moyen pour supprimer 
les jetons affects au noeud de la tdche et au noeud de la ressource critique agencS en parall6le avec 
le noeud de tSche d chaque fois que la fin de Tex^cution de la tdche est d^tect^e, 
un moyen de generation d'un jeton dans un noeud de porte, lors de Tachevement de Texecution corres- 
pondant d tous les noeuds de tSche agenc^s immediatement avant le noeud de porte, et 
un moyen d'ef facement du Jeton dans le noeud de porte apres que le signal de debut de la tdche suivante 
soit transmis. 
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FIG. 2 
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FIG. 3A 



PROGRAM FOR CONTROLUNG FLOW 



Program Main 
begin 

while -END do 
begin 

if (tl is Okay) then 
begin 

with robot2 do 
begin 

R2 ( pi ); 
end 

end 

if (t2 is Okay) then 
begin 

with robot 1 do 
begin 

Rl ( p2 ); 
end 

end 

if (t4 is Okay) then 
begin 

with C robot 1, robot 2 ) do 
begin 

Rl ( p31 ); 
R2 ( p31 ); 
Rl ( p32 ); 
R2 ( p32 ): 
Rl C p33 ); 
R2 C p33 ): 
end 

end 

if (t6 is Okay) then 
begin 

with ( robot 1, robot 2 ) do 
cobegin 

R2 ( p4 ); 

Rl C p5 ); 
CO end 

end 

end 

end 
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FIG. 3B 



PROGRAM FOR ROBOT 1 



PrograjB Rl ( p ) 
begin 

cas« ( p ) 

begin 

SPEEDC50); 
OPENC ); 
DELAY(2); 

MOVEC BCSTATU.BCSTATD) ; 

CLOSEC); 

DELAYC2); 

MOVECBCSTATU); 

IF A = 0 THEN MOVECALTBLUO.ALTBLDO); 
IF A = I THEN MOVECALTBm,ALTBLDl); 
rr A = 2 THEN M0VECALTBUJ2,ALTBLD2); 
OPENC); 
DELAY(2); 

IF A = 0 THEN ttOVECALTBLUO); 

IF A = I THEN MOVECALTBLUI); 

IF A = 2 THEN MOVE( ALTBUJ2); 

A := A -I- 1; 
end 
p31: 
begin 

SPEED<50); 

OPENC); 

DELAY(2); 

HOVECPPASSB); 
end 
p32: 
begin 

MOVECPPASSF); 

CLOSEC); 

PELAYC2); 
fcnd 
p33: 
begin 

MOVEC PPASSB ,DSPOSU ,DSPOSD) ; 
OPENC); 

HOVECDSPOSO.ALTBLUO); 
end 
pA: 

begin 

SPEEDC50); 

OPENC); 

A :« A - 1; 

IF A < 0 THEN A := 0; 

IF A = 0 THEN MOVE(ALTBLUO,ALTBLDO) 

IF A « 1 THEN nOVECALTBLUl.ALTBLDI) 

IF A = 2 THEN ttOVEC ALTBL02,ALTBLD2) 

CLOSEC); 

DELAYC2); 

IF A = O THEN MOVECALTBUIO); 
IF A » 1 THEN MOVECALTBIUl); 
IF A = 2 THEN KOVEC ALT3UJ2); 
MOVECBCSTATU); 
M0VECBCSTATT5); 
OPENC); 
DEI-iYC2); 
MOVECBCSTATU); 
HOVECALTBLUO); 
end 

end 
end 
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FIG. 3C 

PROGRAM FOR ROBOT 2 



Program R2 ( p ) 
begin 

case ( p ) 

Pl: 

begin 
OPENC); 
ARK(LEFT); 

MOVEC FRNTSTATU , FRNTSTATD ) ; 

CLOSEC); 

DELAY(8); 

HOVZC FRNTSTATU); 

ARHC RIGHT); 

KOVE( SBCSTATU , SBCSTATD) ; 

OPENC); 

DELAY(a); 

MOVEC SBCSTATU); 

HOVECCNTTBLUO); 
end 
p31: 
begin 

ARMCtEFT); 

OPENC); 

DELAYC8); 

MOVEC FRNTSTATU , FRNTSTATD) ; 

CLOSEC); 

DELAKS); 

HOVEC FRNTSTATU); 

ARMC RIGHT); 

MOVEC CNTTBLUO , SPASS) ; 
end 
p32: 
begin 

OPENC); 

DELAYCS); 
end 
p33: 
begin 

HOVECCNTTBLUO); 
end 
p4: 

begin 

OPENC); 
ARMC LEFT); 

MOVEC FRNTSTATU , FRHTSTATD ) ; 

CLOSEC); 

DELAYC8); 

MOVEC FRNTSTATU); 

IF A = 0 THEN MOVEC CNTTBLUO. CNTTBLDO); 
IF A = 1 THEN MOVEC CNTTBUJ1,CNTTBLD1); 
IF A = 2 THEN MOVEC CNTTBLU2 ,CNrrBLD2); 
A A + 1; 
OPENC); 
DELAYCa); 
MOVEC CNTTBLUO); 
end 

end 
end 



20 



EP 0 383 506 B1 




F IG. AA EXAMPLE 1 OF EXECUTING PETRINET 



ta 



tb 





Px 










FiG.AB EXAMPLE 2 OF EXECUTING PETRINET 



CRITICAL! 
SECTION 




(CRITICAL 
SECTION 



PROCESS 1 PROCESS 2 

FIG. 5 
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TASK PROGRAM : IRAN 



PROCESS FLOW 
GRAPH :MA1N 



R0B0T1 : 


MCr/E(P0SI_6); 


R0B0T2: 


M0VE{P0SI_7): 


R0B0T2. 


CLOSE; 


R0B0T1 ■ 


OPEN ; 


R0B0T2 


:M0VE(P0S_8); 


R0B0T1 


M0VE(P0S_9); 


R0B0T2 


:M0VE(P0S_10); 




FIG. 8 
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Q START 



ENUMERATE CONDITION GATES 



— 100 



SELECT ONE OF UNSELECTED RESOURCE 
NAME FROM RESOURCE NAME LIST 



REFER TO PROCESS FLOW GRAPH. FIND TASK USING 
THE SELECTED RESOURCE . AND OBTAIN CONDITION 
GATES AT INPUT AND OUTPUT OF THE TASK- 



DESCRIBE RESOUCE NAME AS INPUT OR OUTPUT 
PLACE OF THE CONDITION GATE OBTAINED IN 
STEP102. • 





FIG. 10 
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Q START~^ 



LOAD PROCESS 


> FLOW GRAPH 






LOAD RESOURCE MANAGEMENT GRAPH 






GENERATE U 


NION GRAPN 



-1 1 1 



— 1 12 



'1 15 



1 15 






NO 


USE UNION GRAPH AS IT IS 
FOR PROCESS RESOURCE GRAPH 







1 17 



-1 16 



END 



FIG. 11 
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FIG. 15 
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Q startJ 



151- 



ENUMERATE CONDITION GATES 



152- 



REFER TO PROCESS FLOW GRAPH AND RESOURCE MANAGEMENT 
GRAPH FOR EACH CONDITION GATE , A^ OBTAIN TASK AND 
RESOURCE CONNECTTED TO THE CONDITION GATE- DESCR I BE 
NAME OF OBTAINED TASK OR RESOURCE AS INPUT OR 
OUTPUT PLACE OF THE CONDITION GATE. 



END J 



FIG. 13 
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FIG. 16E 
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